1. Field
The present invention relates to software, and more specifically to methods and systems for configuring a software system.
2. Background
FIG. 1 depicts the security arrangement 100 in a complex administrative software application for limiting access to the resources of the application—that is, to the data used in the application. Complex administrative software applications often have many components with which users can view or interact with the resources associated with the application. Quite often components are added over time to provide more capabilities to the application. The administrative software for each component should be secured so that authorized users can administer each component. However, the various different software components may have any one of several different security constraints. Access Control List (ACL) is one conventional approach for securing administrative software components. ACL serves as an access control mechanism by maintaining and referring to an access control list for each object on a computer to determine whether a particular user is to be given access. Each object is assigned a security attribute identifying its access control list, and the list has an entry for each user with access privileges, such as the ability to read a file, write to the file, or execute the file. Conventional security arrangements, such as ACL, suffer from the drawback of inflexibility.
The security arrangement of FIG. 1 is a user authorization scheme in which users 101-115 are granted authorization to access manageable resources 125 and 127 based on the predefined role to which each respective user has been assigned. Administrative security systems generally have a number of defined roles for users. FIG. 1 depicts four roles which are used in some IBM systems, Administrator 117, Configurator 119, Operator 121 and Monitor 123. These roles may be defined as static roles, with each user assigned to a particular role having the authorization to access the resources of the system at a predefined capability for that role. In the example shown in the figure, each of the roles 117-123 can access all resources—resources 125-127—at the predefined capability for that role. For example, user 101 has been assigned the Administrator 117 role, and therefore has authorization for Administrator level access to all resources, e.g., Resource 125 and Resource 127.
Such approaches which rely upon statically defined roles for granting access sometimes create a problem due to inflexibility. For example, it may be desirable for a user with an administrator role for one resource to not have the administrator role for other resources. As shown in FIG. 1, user 101 and user 103 are both granted the Administrative role 117, and therefore both users can access all the resources in the system as Administrators, in this case, Resource 125 and Resource 127. In some situations a user may request access to one of the resources for performing an action which the application does not have the ability to perform. It would be desirable to be able to add the capability of performing a requested action without requiring a human administrator to perform all of the activities required to reconfigure the application.
What is needed is a way to identify the right software or software component that matches the user's security role and dynamically configure or add new components to the base software.